1. Field of the Invention
The present invention is directed to software development tools for processors and collections of processors that have easily configurable features. In particular, the present invention is directed to software development tools that observe and display the state of a configurable processor or collections of such processors.
2. Background of the Related Art
This invention relates to configurable processors as described in the above-referenced Wang et al. application. To summarize, most processor architectures are fixed. The instructions that a processor can execute are fixed, or limited to a small set of variations, and the information, or state, that they maintain is also fixed or limited to a small set of variations. There are new processors, however, that allow the user to change the architecture of the processor including, but not limited to, addition of instructions and of state. This invention relates to the field of configurable processors. Specifically, the configurability of a processor poses certain problems in software development tools.
This invention also relates to the field of embedded software development. Many computer systems have a CRT for displaying information, a processor, some memory, some sort of fixed storage, a keyboard and other peripherals. These computer systems are equipped to easily display information to the user. Further, they tend to be able to store, run and display many different programs simultaneously. For example, users of Windows computers can run and view many different software programs at the same time.
Other computing systems often have far less hardware associated with them and are far less capable. They often have neither a monitor, a keyboard nor a disk drive. In the simplest case, they may even be completely implemented on a single piece of silicon. Often these systems are capable of storing and running only a single program and have little capability for the visual display of information. Such computing systems are commonly called “embedded systems” because they are embedded in some other system.
Software rarely works properly in its first revision and software developers use a variety of software tools to be able to observe and diagnose software problems. One of the most essential of these tools is a “debugger.” A software program is written in program code, hereinafter referred to as code. Code describes both state and operations to be performed on that state. Generally, the user of a software program cannot view the complete state of that program. This is especially true of embedded software programs. Debuggers allow the software developer to view that state as well as how the state is changed by the operations that are performed on it.
Certainly, debuggers are not the only software development tools that require access to the state of the processor. Though they serve as good example of this class of tool, certain other types of software tools also face the same problems that are faced by debuggers. For example, monitors provide direct visibility to the state of the processor without understanding of the programmatic context and so require this information. Silicon co-verification tools also need this information. Real-time trace capture solutions can need this information. All of these, like debuggers, are generally trying to display state of the processor to the user and some of them are unique—and so do not fall into some particular class of software application. Take as a concrete example the software development environment that is provided by WindRiver in the Tornado 2.0 product. This environment is composed of a variety of different tools. One of these tools is a debugger called CrossWind. But Tornado 2.0 also contains a tool called the “Browser” that allows visibility to the state of the processor. Another tool provided with Tornado 2.0 is called “WindShell” and, again, allows the user to access and view the state of the processor.
In the remainder of this document, the term “debugger” is used to denote any software tool that requires knowledge of the state of the processor to correctly perform its function, whether it performs a debugging function as such is commonly known in the art or not.
The processor and surrounding hardware maintain the state of the program. Some of the state is held in registers that are in the processor, but some of the state can be held in memory or even disk or device registers. So, viewing the state of the program requires viewing the state of the processor and the surrounding hardware. Consequently, tools of this type must be able to access the state of the processor.
The state of software running on a traditional computer system can be viewed by debugging programs running on the same traditional computer system. This is because the computer system is capable of executing and displaying the output of several programs simultaneously. Embedded systems are usually not capable of running and displaying a debugging program. As a result, embedded systems are usually debugged remotely. A remotely debugged system does not itself execute the debugger software but instead provides some mechanism for debugging software running on another computer system to query information about the state of the system. There are a variety of mechanisms that are used to access the state of the processor in remotely debugged systems, but they generally fall into one of three classes.
The first class of mechanisms involves the software tool, a communication channel to the processor and a program called a monitor that runs on the processor. Conceptually, processors generally execute instructions that are referenced by address. The address of the currently executing instruction is called the program counter and the processor executes a series of instructions (a program) by executing instructions from different addresses. The processor executes the monitor by the program counter pointing to one of the addresses containing the monitor. The processor then uses its standard instruction execution mechanism to execute the instructions in the monitor. The monitor retrieves the state of the processor and sends that state of the software tool through the communication channel.
The need to execute the monitor through the standard mechanism of instruction fetch limits the information that can be returned to the software tool. Because the monitor itself uses much of the processor to execute, there are times where the processor is in a condition that the monitor cannot be executed, and therefore, cannot make the state visible to a software tool.
To understand this, consider the debug monitor used by systems running the WindRiver VxWorks operating system. This operating system uses a debug monitor that runs as a task under the operating system. Because the debug monitor runs as a task, it can only report information to the debugging software tool when a task is allowed to run. The operating system does not allow tasks to run when tasks of a higher level are running or when interrupts are being handled. The debug monitor task is also not able to run until a certain point in the initialization process. Consequently debuggers using this debug monitor cannot debug code that is run during the early phases of initialization, that is handling interrupts or that is running at a higher priority than the debug monitor task.
These limitations of monitor programs substantially affect the ability of the debugging tool to aid in diagnosing errors. The other mechanisms to view the state of the processor help to address this limitation.
Before considering the next mechanism, consider the implications of configurable processors (such as those described in the above-referenced applications) for monitor programs. Access to the state of the processor can become problematic in the case of a configurable processor because a monitor, which is responsible for sending state of the processor to the communication channel, must itself know about the state of processor. This problem has been solved in the past by generation of a new monitor for each different processor configuration by the processor generator. The initial release of the Xtensa processor dealt with generation of the monitor in this way. Further, multiple versions of the WindRiver monitor were created for the analogous problem of Intel 486 processors with and without floating point instructions.
This too has problems. Monitor programs are generally stored in ROM or EPROM devices. Programming these devices with a new version of a program generally consumes either additional time or money or both. Further, monitor programs must exist in the same address space as the program to be debugged. A dynamically generated monitor program will vary in its size. Such variation requires changes in additional software for the system to be able to optimally use the available memory space. The present invention addresses this problem.
The second class of mechanism for a remote debugger to access the processor uses special hardware included in the processor for accessing the state of the processor. Many configurable CPUs offer an optional debugging module that allows the normal instruction fetch mechanism to be replaced by a different method that allows an outside agent to specify the instructions to be executed by the CPU. This hardware feature will hereafter be referred to as an “instruction-insertion” feature since it allows an external agent to directly insert instructions to be executed into the processor. Recall that the job of a monitor program is to determine what state to retrieve; retrieve that state; and then put that state into the communication channel. The monitor must do all of these operations using the normal mechanisms of the processor. The instruction-insertion feature allows the determination of state to be done remotely. Further, it generally simplifies the operations performed on the processor which are required to retrieve the state and move that state into the communication channel.
While instruction-insertion systems contain hardware features that do simplify the problems that software must solve, some of the problems that must be solved are simply moved from the processor being viewed to the processor running the debugging software tool. For example, while the processor being viewed no longer has to store the instructions for retrieval of the state of the processor or execute them in the standard mechanism, those instructions must be inserted by the external agent and hence must be available to that agent.
That agent then has the same issues with a configurable processor that a monitor has. Specifically, the external agent (the remote debugging software) must have available the instructions to retrieve and view the state of the processor as well as the instructions to modify the state of the processor. But these instructions will vary depending on the state of the processor. The present invention offers a solution to this problem.
Before moving to the next class of remote-debugging mechanism, there is one more point to make for remote-debugging using instruction insertion mechanisms. Instruction-insertion remote debugging solutions may use more than one additional computing system. Because instruction-insertion mechanisms require specialized hardware interfaces to access their functionality, that interface is sometimes handled by a different computing system. In this situation, a computing system running the software debugging tool has a communication channel to a server software program that has a different communication channel to the instruction-insertion mechanism. The role of this server program is to translate requests from the software debugging tool into commands to the instruction-insertion mechanism. The server software faces some of the problems faced by the monitor program in this system. The server software must know about the new processor state and new instructions to access that state. One solution to this problem is to rebuild the server software for each processor. But again, the server software faces some of the same issues of convenience and efficiency. The present invention offers a solution to this problem.
The final class of mechanism for a remote debugger to access the state of the processor is through use of direct state scanning. Some hardware options allow the state of the processor to be read directly out of the processor without execution of any instructions (inserted or otherwise).
Fabrication of application-specific chips makes the use of configurable processors possible. Often these application-specific chips will have more than one processor on them. The system designer determines the number of processors in this collection and the arrangement of those processors and their relationship to non-processor elements. Remote software debugging solutions must work in this type of environment. This invention solves problems for debugging software that arise from this environment.